Section: New Results

New features of Polychrony

Participants : Loïc Besnard, François Fabre, Thierry Gautier, Paul Le Guernic.

Some new features have been implemented in the Signal toolbox of the Polychrony toolset:

• It is now possible to declare virtual objects (types, constants and process models), which are distinguished from external objects, though objects declared as external may also be redefined in the context of declaration. The actual value of an object declared as virtual is provided in the syntactic context of declaration or in a module. A module provides a context of definition for some of the objects described as virtual in the model or the module containing the module importation command. These virtual objects are overridden in this way if they are imported (as corresponding objects with the same name) from an imported module, or transitively, from a module imported in an imported module.

• Process models as (static) parameters have been implemented: the formal parameters of the interface of a process model can contain process model parameters, that appear as a formal name of process model typed with a process model type. The call of a process model sets up an expansion context in which an effective process model, designated by its name, is associated with each formal model.

• The connection to the SynDEx tool (http://www.syndex.org/ ) has been completed as follows. So far, only the functional part of a given application described in Signal was translated as a corresponding “algorithm” in SynDEx. The multicomponent architecture (typically, processors interconnected through communication medias) and the mapping of the algorithm onto the architecture had to be provided directly within SynDEx. As the polychronous model may be used as intermediate common formalism for applications described in languages where these aspects may be specified (this may be the case in AADL, for instance), they have to be taken into account in the translation. Thus, required elements of the architecture and distribution constraints are described using specific “pragmas” in Signal. These features are then translated into the SynDEx formalism. Using all these information, SynDEx can explore the possible implementations of the algorithm onto the multicomponent.

Moreover, we have redefined the meta-model of Signal in Ecplise, now called SSME (for Signal Syntax meta-model under Eclipse). The SME meta-model, that was used previously, suffered from several drawbacks. It was not fully complete in some parts of the language and, due to design choice, required a strict separation between clock and data flow relations. Thus specific program transformations had to be applied, which did not facilitate traceability. SSME is a full syntax oriented meta-model of Signal, very close to the abstract syntax that is used in the Signal toolbox. Compared to SME, this facilitates model transformations and traceability requirements, which are the primary objectives for its use. The transformation of AADL models into Signal, for instance, now uses the SSME meta-model.